29% completed
Cache Invalidation Strategies
While caching can significantly improve performance, we must ensure that the data in the cache is still correct—otherwise, we serve out-of-date (stale) information. This is where cache invalidation comes in.
-
Ensure Data Freshness
- When the underlying data changes—say a product’s price updates in your database—you must mark or remove the old (cached) data so users don’t see stale information. This process is called “cache invalidation.”
- Without invalidation, caches will keep serving outdated data and lead to inconsistencies across your application.
-
Maintain System Consistency
- Large systems often have multiple caching layers. If any of these layers serve old data while others serve new data, users can encounter conflicting information.
- Properly invalidating caches at each layer helps maintain a consistent view of your system’s state.
-
Balance Performance and Accuracy
- Cache invalidation strategies (e.g., time-to-live/TTL, manual triggers, event-based invalidation) are designed to minimize the performance cost of continuously “refreshing” the cache.
- The goal is to keep data as accurate as possible while still benefiting from the high-speed data retrieval that caching offers.
-
Reduce Errors and Mismatched States
- When caches go stale, you risk presenting users with wrong information or invalid results (e.g., displaying an out-of-stock product).
- By strategically invalidating caches when data changes, you reduce the odds of users experiencing buggy or contradictory behavior.
There are three main cache invalidation schemes that are used:
1. Write-through cache
Under this scheme, data is written into the cache and the corresponding database simultaneously. The cached data allows for fast retrieval and, since the same data gets written in the permanent storage, we will have complete data consistency between the cache and the storage. Also, this scheme ensures that nothing will get lost in case of a crash, power failure, or other system disruptions. Although, write-through minimizes the risk of data loss, since every write operation must be done twice before returning success to the client, this scheme has the disadvantage of higher latency for write operations.
2. Write-around cache
This technique is similar to write-through cache, but data is written directly to permanent storage, bypassing the cache. This can reduce the cache being flooded with write operations that will not subsequently be re-read, but has the disadvantage that a read request for recently written data will create a “cache miss” and must be read from slower back-end storage and experience higher latency.
3. Write-back cache
Under this scheme, data is written to cache alone, and completion is immediately confirmed to the client. The write to the permanent storage is done based on certain conditions, for example, when the system needs some free space. This results in low-latency and high-throughput for write-intensive applications; however, this speed comes with the risk of data loss in case of a crash or other adverse event because the only copy of the written data is in the cache.
4. Write-behind cache
It is quite similar to write-back cache. In this scheme, data is written to the cache and acknowledged to the application immediately, but it is not immediately written to the permanent storage. Instead, the write operation is deferred, and the data is eventually written to the permanent storage at a later time. The main difference between write-back cache and write-behind cache is when the data is written to the permanent storage. In write-back caching, data is only written to the permanent storage when it is necessary for the cache to free up space, while in write-behind caching, data is written to the permanent storage at specified intervals.
Cache Invalidations Methods
Here are the famous cache invalidation methods:
Purge
The purge method removes cached content for a specific object, URL, or a set of URLs. It’s typically used when there is an update or change to the content and the cached version is no longer valid. When a purge request is received, the cached content is immediately removed, and the next time that URL or key is requested, the cache must fetch a fresh copy from the origin server, store it, and return it to the client.
Refresh
Fetches requested content from the origin server, even if cached content is available. When a refresh request is received, the cached content is updated with the latest version from the origin server, ensuring that the content is up-to-date. Unlike a purge, a refresh request doesn’t remove the existing cached content; instead, it updates it with the latest version.
Ban
The ban method invalidates cached content based on specific criteria, such as a URL pattern or header. When a ban command is issued (e.g. “ban all URLs matching /category/holiday-sales”), the cache doesn’t purge those objects at once. Instead, it adds the criteria to a ban list. From that point on, every client request is checked against the ban list; if a requested resource matches an invalidation rule, the cache will treat it as stale and fetch a fresh version from the origin, then update the cache. Items not matching any ban rule continue to be served normally. Over time, as banned items are requested and refreshed, they get replaced with updated content and the ban rule can eventually be dropped once all outdated content is gone.
What is the difference between Purge and Ban?
- Purge is like doing a “hard delete” on a cache entry: it is removed right away so that any subsequent requests must go back to the origin server. Also, Purge typically works on a specific cache key (e.g., a URL) so we know exactly which object is being deleted.
- Ban is more like flagging an entry (or set of entries) as no longer valid. The entry may still reside in memory until eventually cleaned up, but it won’t be served because it has been marked as invalid. Also, you can ban a group of objects by specifying conditions (such as a pattern in the URL or a header value), which makes it flexible when you need to invalidate multiple related objects.
Time-to-live (TTL) expiration
This method involves setting a time-to-live value for cached content, after which the content is considered stale and must be refreshed. When a request is received for the content, the cache checks the time-to-live value and serves the cached content only if the value hasn’t expired. If the value has expired, the cache fetches the latest version of the content from the origin server and caches it.
Stale-while-revalidate
This method is used in web browsers and CDNs to serve stale content from the cache while the content is being updated in the background. When a request is received for a piece of content, the cached version is immediately served to the user, and an asynchronous request is made to the origin server to fetch the latest version of the content. Once the latest version is available, the cached version is updated. This method ensures that the user is always served content quickly, even if the cached version is slightly outdated.
On this page
Cache Invalidation Strategies
- Write-through cache
- Write-around cache
- Write-back cache
- Write-behind cache
Cache Invalidations Methods
Purge
Refresh
Ban
Time-to-live (TTL) expiration
Stale-while-revalidate